Dynflow uses locks placed into dynflow_coordinator_records table for two
reasons. One is to ensure certain things (delay planed watcher, world
invalidation and so on) are globally unique, the other is to ensure any
exceution plan is being worked on in only one world.

Sidekiq shutdown raises an exception in the executing thread, which then
propagates up the stack, executing all ensure blocks encountered along
the way. This could lead to the per-execution-plan kind of locks getting
unlocked prematurely. The originally reported issue was that execution
plans were being left in planning, without having a relevant planning
lock left in the database and therefore not being picked up during world
invalidation.

Furthermore, because the way Sidekiq performs shutdowns is a half-clean
shutdown, world termination hooks are being called, which prune all
locks belonging to the terminating world. This is nice for the
globaly unique kind of locks, but causes an issue for the
per-execution-plan kind of locks.

This change ensures that the per-execution-plan locks are left around on
world termination so that they can be dealt with properly during
invalidation, where we actually have time to do something with them.

World invalidation previously relied on world-level lock being present.
All locks belonging to the world which left that lock around would then
be invalidated. If there were any orphaned locks, those would be just
deleted.

With this change, we do proper invalidation for orphaned locks.